home *** CD-ROM | disk | FTP | other *** search
/ Chip 2000 September / Chip_2000-09_cd1.bin / sharewar / Slunec / app / 16 / ANIM.SWG / 0019_AutoDesk Animator FLIcs.pas < prev   
Pascal/Delphi Source File  |  1997-05-12  |  7KB  |  163 lines
  1. Autodesk  Animator  files explanation (.FLI  only  excerpted). I believe
  2. that  the  original programmer wrote up  this doc. It's correct, as I've
  3. used  the info to realtime playback stock  .FLIs on a 680x0 machine. All
  4. numbers  in  a  .FLI  file  are in  Intel  format,  so  you  may have to
  5. compensate for that, of course. - kevin
  6.  
  7. 8.1 Flic Files (.FLI)
  8.  
  9.      The  details  of  a FLI file  are  moderately complex, but the idea
  10. behind  it is simple: don't bother storing the parts of a frame that are
  11. the same as the last frame. Not only does this save space, but it's very
  12. quick. It's faster to leave a pixel alone than to set it.
  13.  
  14.      A  FLI file has a 128-byte header followed by a sequence of frames.
  15. The  first  frame is compressed  using a bytewise run-length compression
  16. scheme. Subsequent frames are stored as the difference from the previous
  17. frame.  (Occasionally  the  first  frame  and/or  subsequent  frames are
  18. uncompressed.)  There  is  one  extra frame at  the  end  of a FLI which
  19. contains the difference between the last frame and the first frame.
  20.  
  21.      The FLI header:
  22.  
  23.      byte size name      meaning
  24.      offset
  25.  
  26.      0    4    size      Length of file, for programs that want
  27.                          to read the FLI all at once if possible.
  28.      4    2    magic     Set to hex AF11.  Please use another
  29.                          value here if you change format (even to
  30.                          a different resolution) so Autodesk
  31.                          Animator won't crash trying to read it.
  32.      6    2    frames    Number of frames in FLI.  FLI files have
  33.                          a maxium length of 4000 frames.
  34.      8    2    width     Screen width (320).
  35.      10   2    height    Screen height (200).
  36.      12
  37.      14   2    flags     Must be 0.
  38.      16   2    speed     Number of video ticks between frames.
  39.      18   4    next      Set to 0.
  40.      22   4    frit      Set to 0.
  41.      26   102  expand    All zeroes -- for future enhancement.
  42.  
  43.      Next are the frames, each of which has a header:
  44.  
  45.      byte size name      meaning
  46.      offset
  47.      0    4    size      Bytes in this frame.  Autodesk Animator
  48.                          demands that this be less than 64K.
  49.      4    2    magic     Always hexadecimal F1FA
  50.      6    2    chunks    Number of 'chunks' in frame.
  51.      8    8    expand    Space for future enhancements. All zeros.
  52.  
  53.      After  the  frame  header come the  chunks  that make up the frame.
  54. First  comes  a color chunk if the  color  map has changed from the last
  55. frame. Then comes a pixel chunk if the pixels have changed. If the frame
  56. is  absolutely  identical to the last frame  there  will be no chunks at
  57. all.
  58.  
  59.      A chunk itself has a header, followed by the data.  The
  60. chunk header is:
  61.  
  62.      byte size name meaning
  63.      offset
  64.      0    4    size Bytes in this chunk.
  65.      4    2    type Type of chunk (see below).
  66.  
  67.      There are currently five types of chunks you'll see in a FLI
  68. file:
  69.  
  70.      number    name      meaning
  71.      11        FLI_COLOR Compressed color map
  72.      12        FLI_LC    Line compressed -- the most common type
  73.                          of compression for any but the first
  74.                          frame.  Describes the pixel difference
  75.                          from the previous frame.
  76.      13        FLI_BLACK Set whole screen to color 0 (only occurs
  77.                          on the first frame).
  78.      15        FLI_BRUN  Bytewise run-length compression -- first
  79.                          frame only
  80.      16        FLI_COPY  Indicates uncompressed 64000 bytes soon
  81.                          to follow.  For those times when
  82.                          compression just doesn't work!
  83.  
  84.      The  compression  schemes are all  byte-oriented. If the compressed
  85. data  ends up being an odd length a  single pad byte is inserted so that
  86. the FLI_COPY's always start at an even address for faster DMA.
  87.  
  88. FLI_COLOR Chunks
  89.  
  90.      The  first  word  is the number of  packets  in this chunk. This is
  91. followed  directly  by the packets. The first  byte of a packet says how
  92. many  colors  to skip. The next byte  says how many colors to change. If
  93. this  byte  is zero it is interpreted  to mean 256. Next follows 3 bytes
  94. for each color to change (one each for red, green and blue).
  95.  
  96. FLI_LC Chunks
  97.  
  98.      This  is  the most common, and  alas, most complex chunk. The first
  99. word  (16  bits)  is the number of  lines  starting  from the top of the
  100. screen  that are the same as the  previous frame. (For example, if there
  101. is  motion only on the bottom line of screen you'd have a 199 here.) The
  102. next  word is the number of lines that do change. Next there is the data
  103. for the changing lines themselves. Each line is compressed individually;
  104. among  other things this makes it much easier  to play back the FLI at a
  105. reduced size.
  106.  
  107.      The  first  byte of a compressed line  is  the number of packets in
  108. this  line.  If the line is unchanged  from the last frame this is zero.
  109. The format of an individual packet is:
  110.  
  111.  skip_count
  112.  size_count
  113.  data
  114.  
  115.      The  skip count is a single byte. If more than 255 pixels are to be
  116. skipped it must be broken into 2 packets. The size count is also a byte.
  117. If  it is positive, that many bytes of  data follow and are to be copied
  118. to  the screen. If it's negative a  single byte follows, and is repeated
  119. -skip_count times.
  120.  
  121.      In  the worst case a FLI_LC frame can be about 70K. If it comes out
  122. to  be  60000 bytes or more  Autodesk Animator decides compression isn't
  123. worthwhile and saves the frame as FLI_COPY.
  124.  
  125. FLI_BLACK Chunks
  126.  
  127.      These  are  very simple. There is  no  data associated with them at
  128. all.  In  fact they are only generated  for  the first frame in Autodesk
  129. Animator after the user selects NEW under the FLIC menu.
  130.  
  131. FLI_BRUN Chunks
  132.  
  133.      These  are  much like FLI_LC chunks  without  the skips. They start
  134. immediately  with the data for the first line, and go line- by-line from
  135. there.  The first byte contains the number  of packets in that line. The
  136. format for a packet is:
  137.  
  138.  size_count
  139.  data
  140.  
  141.      If  size_count is positive the data consists of a single byte which
  142. is  repeated  size_count  times.  If  size_count  is  negative there are
  143. -size_count  bytes  of data which are  copied to the screen. In Autodesk
  144. Animator  if the "compressed" data shows  signs of exceeding 60000 bytes
  145. the frame is stored as FLI_COPY instead.
  146.  
  147. FLI_COPY Chunks
  148.  
  149.      These are 64000 bytes of data for direct reading onto the screen.
  150.  
  151.  -eof-
  152.  
  153. Notes: Since these are animations, the last frame will delta into a copy
  154. of  the  first  one (which was  usually  a large BRUN chunk). Therefore,
  155. looping  should  go  back to the _second_  frame  chunk (usually a LC or
  156. COLOR chunk) instead of all the way back to the file beginning, to avoid
  157. a "stutter" caused by unnecessarily redecoding the original frame. Also,
  158. a  very few files may have palette animation, so write your code so that
  159. COLOR chunks can be found at any time. - kevin
  160.  
  161.  
  163.